IP Multimedia Subsystem (IMS) is the technology defined by the Third Generation Partnership Project (3G) to provide IP Multimedia services over mobile communication networks. IMS provides key features to enrich the end-user person-to-person communication experience through the use of standardised IMS Service Enablers, which facilitate new rich person-to-person (client-to-client) communication. An IMS network is able to connect to both PSTN/ISDN (Public Switched Telephone Network/Integrated Services Digital Network) as well as the Internet.
IMS provides a dynamic combination of voice, video, messaging, data, etc. within the same session. By growing the number of basic applications and the media which it is possible to combine, the number of services offered to the end users will grow, and the inter-personal communication experience will be enriched. This will lead to a new generation of personalised, rich multimedia communication services, including so-called “combinational IP Multimedia” services.
The IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between user terminals (or user terminals and application servers). The Session Initiation Protocol is a text-based protocol specified by the Internet Engineering Task Force (IETF) in RFC 3261, similar to Hypertext Transfer Protocol (HTTP) and Simple Mail Transfer Protocol (SMTP), for initiating interactive communication sessions between users. Such sessions include voice, video, chat, interactive games, and virtual reality. Extensions to SIP are also specified in several other IETF specifications.
SIP makes it possible for a calling party to establish a packet switched session to a called party (using so-called SIP User Agents (UA) installed in the User Equipment (UE)) even though the calling party does not know the current IP address of the called party prior to initiating the call. The Session Description Protocol (SDP), carried by SIP signalling, is used to describe and negotiate the media components of the session. Whilst SIP was created as a user-to-user protocol, IMS allows operators and service providers to control user access to services and to charge users accordingly.
FIG. 1 of the accompanying drawings illustrates schematically how the IMS fits into the mobile network architecture in the case of a GPRS/PS access network (IMS can of course operate over other access networks). Call/Session Control Functions (CSCFs) operate as SIP proxies within the IMS. The 3G architecture defines three types of CSCFs: the Proxy CSCF (P-CSCF) which is the first point of contact within the IMS for a SIP terminal; the Serving CSCF (S-CSCF) which provides services to the user that the user is subscribed to; and the Interrogating CSCF (I-CSCF) whose role is to identify the correct S-CSCF and to forward to that S-CSCF a request received from a SIP terminal via a P-CSCF.
SIP offers flexibility in how different services associated with a session may be invoked and there are services where the direct contact address of a particular user or service may need to be transferred by a second user or service to a third party. One common way of doing this is by using the URI as received in the Contact header of a SIP message. The Contact header is normally used to provide for direct communication between SIP entities such that subsequent requests will be directed to the URI within the Contact header. However, in some networks the Contact header of a SIP message may be mapped to that of, for example, a Back-to-Back User Agent (B2BUA) such as a Session Border Controller (SBC) or some Application Servers, such that the direct contact address of the user or service does not reach the recipient SIP entity. Messages intended for the user or service must then pass through the same nodes that performed the original mapping, as these nodes are required to perform inverse mapping of the address. Such inverse mapping is only possible if the message is sent within a dialog and the message follows the same path as the original message.
An example of a service that may require an address to be transferred to a third party is that of a conference. FIG. 2 illustrates a simplified signalling flow of a scenario wherein a first SIP user agent (within UE-A) creates an ‘ad hoc’ conference and subsequently requests that a second SIP user agent (within UE-B) dial into that conference. The steps performed are as follows:                R1. UE-A sends an INVITE request to a SIP server (conference server or conference factory) via an SBC and an Application Server (AS). The Request-URI of the INVITE is set to the URI of the SIP server acting as a conference factory (conf-factory-URI).        R2. The SIP server accepts the INVITE, creates a focus for the conference and sends a response to UE-A with the Contact header set to the URI of the conference focus (conf-URI) and with the addition of the “isfocus” feature tag, as defined in RFC 4579.        R3. The AS in this example acts as a B2BUA, maps the Contact header to the URI of the AS (AS-URI) also containing the “isfocus” feature tag, and forwards the response to the SBC.        R4. The SBC also acts as a B2BUA and maps the Contact header to its URI (SBC-URI), again including the “isfocus” feature tag, and forwards the response to UE-A.        R5. UE-A requests that UE-B join the conference using the REFER request. According to 3GPP TS 24.147, the Refer-To header is set to the conference URI learnt during conference establishment that, due to address mapping at the SBC, is the SBC-URI.        R6. The REFER is routed using normal SIP routing to UE-B.        R7. In attempting to join the conference, UE-B sends an INVITE request using the URI in the Refer-To header as the Request URI. As described above the Refer-To header is set to the URI of the SBC, such that the INVITE sent by UE-B is routed to the SBC and not to the conference focus.        
The problem with existing technology is that a third party i.e. UE-B, will not be able to join the session due to mapping of the direct contact address of the user or service.